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HELD OF THE INVENTION 

Hie present invention relates to netwodc synchronization and moreparticulariy to 
softvme for syniAronizmg the pli^back of a mnltm 
i^paratuses. 
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Systems such as the Internet typically are point-to-point (or nnicast) systems i 
which a message is converted into aseries of addressed packets which are routed 
fiomasourccnodeftaou^aphiialilyofiouteistoadestinationnode. Inmost 
oomnmnication protocols the packet mchides aheader which contains the addresses 
of the source and the destination nodes as well as a sequence number which specifies 
fbs padcet's order in tiie message. 



hi general, these systems do not have the capability of broadcasting amessage fiom 
a source node to all the other nodes m flie network because such a capability is rarely 

25 of much use and couW easfly overload the n«*woik. However, there are situations 
where ft is desirable for one node to commraiioate with some subset of all the nodes. 
For exarapl«s, multi-party conferencing capabiHty analogous to that found in the 
piibUctelephonB system and broadcasting to afimitednumberof nodes are of 
considerable mterestto users of packet-switchednetworks. To satisfy such 

30 demands, packets destined for several recipients have been encapsulated in a unicast 
packet and forwarded from a source to a point in a network where the packets have 
been replicated and forwarded on to aU desired recipients. This technique is known 



as IP Multicasting and the network over wliich such packets are louted is referred to 
as the Multicast Backbone or MBONE. More recently, routers have become 
available which can route flie multicast addresses (class D addresses) provided for in 
communication protocols such as TCP/IP and UDP/IP. A multicast address is 
5 essentially an address foe a groiq> of host computers who have indicated their desire 
to participate in that groi^. Thus, a multicast packet can be routed fiom a source 
node tfarougjb a pluraUty of multicast routers (or mrouteis) to one or more devices 
receiving the multicast packets. From there the packet is distributed to all the host 
computers that are mambera of the multicast group. 

10 

These techniques have been used to provide on the hitemet audio and video 
conferencmg as well as radio-like broadcasting to groups of interested parties. See, 
for example, K. Savetz et aL MBONE Multicasting Tomorrow's Internet QDG 
Books Worldwide Inc^ 1996). 

15 

Further details concerning technical aspects of multicasting may be found in the 
Meaiet docum^ts Request for Comments (KPC) 1 1 1 2 and 1 458 which are 
rqprodnced at ^i^pendices A and B of the Savetz book and in D. P. Brutaman et al., 
"MBONB provides Audio and Video Across the hitemet," IEEE Computer, Vol. 27, 
20 No, 4, pp. 30-36 (April 1994), all of which are incorporated herein by reference. 

Multimedia computer systems have become increasingly popular over the last 
several years due to their versatihty and their interactive presaitation style. A 
multimedia computer system can be defined as a computer system havipg a 

25 combination ofvideo and audio outputs for presentation of audio-visual displays. A 
modem multimedia computer system ^pically includes one or more storage devices 
such as an optical driv^ a CD-ROM, a hard drive, a videodisc, or an audiodisc, and 
audio and video data are typically stored on one or more of these mass storage 
devices. In some file formats the audio and video are interieaved together in a single 

30 file, while m other formats tbe audio and video data are stored in different files, 
many times on different storage media. Audio and video data for a multimedia 
display m^ also be stored in separate computer systems that are networked together. 



Id (his instance^ the computer system presenttng the multimedia display would 
receive aportion of the necessary data from the otiher computer system via fiie 
netwodc cabling. 

5 Graphic images used in Windows multimedia applications can be created in either of 
two ways, these being bit-mapped images and vector-based images. Bit-mapped 
images comprise aphirality of picture elements Q>ixels) and are created by assigning 
a color to each pixel inside the image boundary. Most bit-m^ed color images 
require one byte per pixel for storage, so large bit-mapped images create 

10 correspondingly large files. For example, a fuU-screoi, 256-color image in 640-by^ 
480-pixel VGA mode requires 307^00 bytes of storage;, if &e data is not 
compressed. Vector-based images are created by defining the end points, thickness, 
color, pattem and curvatore of lines and solid objects comprised within the image. 
Hius;, a vector-based image includes a definition which consists of a nmnerical 

15 representation of the coordinates of the object re&rmced to a comer of the image. 

Bit-ma^ed images are the most prevalent type of image storage formal and die 
most common bit-m^ed-unage file ibrmats are as follows. A file format referred 
to as BMP is used for Windows bit-m^ files in 1-, 2-, 4-, 8-, and 24-bit color 

20 depibs, BMP files contain a hit-mqs head^ Hhst defines the size of the image, the 
numbCT of color planes, the type of compression used (if any), and the palette used. 
The Windows DIB (device-independent bit-map) format is a variant of the BMP 
format that inchides a color table defining the RGB (red green blue) values of the 
colors used. Other types ofbit-mq> formats include the HF (tagged image format 

25 file), file PCX (Zsoft Personal ComputCT Paintbrush Bitmap) file format, the GIF 
(gc^hics intorhange file) format, and the TGA (Texas Instruments Gr^hic 
Architecture) file format 

Hie standard Windows format for bit-m^ed images is a 2S6-coIor device- 
30 indqiendent bit m^ (DIB) with a BMP (the Windows bit-mapped file format) or 
sometimes a DIB extension. The standard Windows format for vector-based images 
is referred to as WMF (Windows meta file). 



Full-motion video implies fliat video images shown on the computer's screen 
simulate ftose of a television set with identical (30 fiames-per-second) fiame rates, 
and that these images are acconq[)anied by bigh-quality stereo sound. A large 
S amount of storage is required for bigb-iesolution color images^ not to mention a fiill- 
motion video sequence. For example, a single frame of NTSC video at 640-b)^40&- 
pixelresolutionwithie-bitcolorrequiresSlZKofdataperfi^ AtSOflamesper 
second, over IS Megabytes of data storage are required for each second of fiill 
motion video. Due to the large amount of storage required for full motion video, 
10 various types of video conq>ression algorithms are used to reduce the amount of 
necessary storage. Video compression can be performed either in real-time, i.e., on 
the fly during video capture^ or on the stored video file after the video data has been 
C2q;>tured and stared on the media, hi addition, differexit video compression methods 
exist for still grq)hic images and jfor full-motion video. 

15 

Exarnples of video data conqiression for still gr^hic images are RLE (run-length 
^icoding) and JPEG (Joint FhotogrEpMcE3q)eits Group) compressior^ RLE is the 
standard coinpressionmediod&rin^ows BMP and DIB files. The RLE 
compression method operates by testing for duplicated pixels in a single line of the 

20 bit map and stores the numb^ of consecutive duplicate pixels rather than the data for 
the pixel itself JPEG compression is a group of related standards that provide either 
lossless (no image quality degradation) or lossy (imperc^tible to severe 
degradation) compression types. Although JPEG conqnnession was designed for the 
compression of still images rather than video, several manufiuturers siq>ply JPEG 

25 compression adqster cards for motion video applications. 

In contrast to ccmipression algorithms for still images, most video co^^)ression 
algorithms are designed to compress fiill motion video. Video compression 
algorithms for motion video generally use a concept referred to as interfiame 
30 compreOTon, which involves storing only the differences between successive frames 
in tiie data file. Interfiame compression begins by digitizing die entire image of a 
keyframe. Successive firames are conq>ared with the key firame, and only the 



difibrences between the digitized data from the key frame and fix>m the successive 
frames are stored. Periodically, such as when new scenes are displayed, new key 
frames are digitized and stored, and subsequent comparisons begin fiom this new 
reference point. It is noted that interfirame compression ratios are content-dependent, 
5 i.e., if die video clip being compressed includes many abrupt scene transitions fiom 
one image to anoAer, the ccnnpression is less efficient Examples of video 
conq>ressionMdbdchuse aninterfiame conqmession technique are MPEG, DVIand 
Indeo, among others. 

1 0 MPEG (Moving Pictures Exp^ Group) compression is a set of methods for 

conqnression and decompression of full motion video images that uses the interfiame 
conq)ression technique described above. The MPEG standard requires that sound be 
recorded simuttaneousty with the video data, and the video and audio data are 
interleaved in a single jQIe to atten^t to maintain &e video and audio synchronized 

15 during playback. The audio data is typically conq)ressed as well, and the MPEG 
standard specifies an audio compression me&od referred to as ADPCM (Adaptive 
Difiersitial Pulse Code Modulation) for audio data. 

A standard refened to as Digital Video Interactive (DVQ format developed by Intel 
20 Corporation is a conq)ression and storage format for full-motion video and hi^- 
jSdelity audio data. TTie DVE standard uses interframe compression techniques 
similar to that of the MPEG standard and uses ADPCM compression for audio data. 
The compression method used in DVI is referred to as RTV 2.0 (real time video), 
and this compression method is incoiporated into IntePs AVK (audio/video kernel) 
25 software for its DVI product line. IBM has adoptedDVI as the standard for 

displaying video fiMT its Ultimedia product tme. The DVI file format is based on the 
Intel i7S0 chipset and is supported through the Media Control Ihtetficc (MOE) for 
Wndows. Microsoft and Intel jomtly announced the action of the DV Md 
(digital video media control interface) command s^ for Windows 3.1 in 1992. 

30 

The Microsoft Audio Video hiterleaved (AVI) format is a special compressed file 
structure format designed to enable video images and synchronized sound stored on 



• ) 



CD-ROMs to be played on PCs with standard VGA displays and audio adapter 
cards. The AVI compiession inefliod uses an int^&ame method, j.e., the differences 
between successive jSrames are stored in a manner similar to the compression 
methods used in DVI and MPEG. The AVI format uses symmetrical software 
5 compression-deconq^iession techniques, i.e., both conqirBssion and decompression 
are p^ormed in real time. Thus AVI files be created by recording video images 
and sound in AVI fomiat fiom a VCR or television broadcast in real time, if raough 
free hard disk space is available. 

10 Despite these compression algorithms, it is very difficult to simultaneously multicast 
multimedia matmal due to bandwidth lestrainls. This problem is unavoidable wiA 
presoit technology smce such large amounts of data must be transferred over 
networks such as the Intemet fiom a single host servCT to numerous client 
computers. 

15 



SUMMARY OF THQE INVENTION 

A system, melhod and article of mamifacture are provided for identiQing playback 
devices of a plurality of climt ^paratuses which are networked to simultaneously 
5 playback an event A type of the pla:^ack device of each of the client apparatuses is 
first identified. A command associated wiA the identified type of the playback 
device is then looked up in a table. Tliereafter,fiie command is sent to fte 
corresponding client apparatus for beginning the playback of the event 
simultaneously with the playback of the event on each of flie remaining cUent 
10 apparatuses. 



n 



BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will be better understood when considemtiQn is given to fhe following 
detailed description theieo£ Sudi description makes reference to the annexed 
S drawings wherein: 

Figure 1 is a schematic diagram of a hardware inqslementation of one embodiment 
odbe present invention; 

1 0 Eguie 2 illustrates a flowchart delineating a method for synchronizing an event on a 
plurality of client ^aratuses in accordance with one embodiment of the present 
invention; 

Figure 3 lUustrates a flowchart delineating a method for storing synchronization 
15 information for subsequ^t playback of an event in accordance with one 
embodiment of the present invention; 

Figure 4 illustrates a flowchart setting forth a method for providing ovolays during a 
synchronized event on a plurality of client apparatuses in accordance with one 
20 embodiment of the present invention; 

Figure 5 illustrates a flow diagram for delayed synchronization of an event on a 
plurality of client ^>paratuses in accordance with one embodiment of the present 
invention; 

25 

Figure 6 illustrates a flow diagram for providing information on a synchronized 
event on a phirality of client apparatuses in accordance with one embodiment of the 
present invention; 

30 Figure 7 illustrates a method for creating a synchiomzar object in order to playback 
an event simultaneously on a plurality of client apparatuses in accordance with one 
embodiment of fhe present invention; 



i 



Figure 8 illustrates a flowchart for affording a scheduler object adapted to &cilitate 
the playback of an event simultaneously on a plurality of networked client 
^paratoses in accordance with one embodim^t of the present invention; 

5 

Figure 9 is a flowchart delineating a method for identi^ing a plurality of events 
which are played back simultaneously on a plurality of netwojdced client apparatuses 
in accordance with one embodiment of the present invention; 

10 Figure 10 shows a flowchart delineatmg a technique for interfiadng a plurality of 
differmt types of playback devices of client apparatuses which are networked to 
shnultaneously playback an event in accordance with one embodimeat of the present 
invention; 

15 Figure 11 iUustrates die manner in which a layer &ctory is created in accordance 
with one embodiment of the present invention; 

Figure 12 ilhisfrates the manner in which user requests are processed in acooidance 
with one embodiment of the present invention; 

20 

Figures 13-16 illustrate various class/component diagrams in accordance with one 
embodiment of the present invention; 

Figure 17 illustrates a logical sequ^ce diagram in accordance with one embodiment 
25 of die present invention; 

Figure 18 illustrates a logical sequence diagram that shows server side collaboradon 
in accordance with one embodiment of the preset invention; and 

30 Figure 19 illustrates a logical sequence diagram showing client side collaboration in 
accordance with one embodim^t of the present invention. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Figures 1-19 illustrate a system for synchronizing an event on a plxirality of client . 
^aratuses. Prior to use, an event is stored in memory on at least one of die client 
5 apparatuses. Such client apparatuses are ad^ted to be connected to a network along 
with a host coiiq)Utei(s). In operation^ information is transmitted from the host 
computer to the at least one client ^aratus utilizing the network. Hus information 
allows for the simultaneous and synchronous playback of the event on each of tiie 
client qjparatuses. 

10 

In various embodiments, die client ^paratuses may take ttte form of computers, 
televisions, stereos, home appliances, or any other types of devices. In one 
embodiment, &e client apparatuses and die host computer each include a conqputer 
such as an IBM compatible computer, Apple Macintosh computer or UNDC based 
IS workstation. 

A r^resoitative hardware environment is dqpicted in Figure 1, which illustrates a 
typical hardware configuration of a wodcstation in accordance with a prefened 
embodiment having a central processing unit 110, such as a microprocessor, and a 

20 number of othor units interconnected via a system bus 112. The workstation shown 
in Figure 1 inchides a Random Access Memory (RAM) 114, Read Only Memory 
(ROM) 116, an I/O adapter 118 for connecting peripheral devices such as disk 
storage units 120 (i.e. DVD playback device) to die bus 112, a user tnter&ce adq>ter 
122 ibr connecting a keyboard 124, a mouse 126, a speaker 12S, a microphone 132, 

25 and/or odier user inter&ce devices such as a touch screen (not shown) to the bus 
112, conummication ad^t^ 134 for connecting the workstation to a communication 
n^work (e.g., a data processing network) and a display ad^ter 136 for connecting 
the bus 112 to a display device 138, The workstation typically has resident dimon 
an operatir^ system such as the Microsoft Windows NT or Windows/95 Operating 

30 SystOTi (OS), die IBM OS/Z operating system, die MAC OS, or UNIX operating 
s^tem. Those skilled in the art will appreciate that the present invention may also 
be implemented on platforms and operating systems otfao- than those mentioned. 




A preferted embodiment is written using JAVA, C» and flie C++ language and 
ndlizes object oriented programniing methodology. Object oriented progranmiing 
(OOP) has become increasingly used to develop complex applications. As OOP 
5 moves toward the mainstream of software design and development, various software 
solutions require adaptation to make use of the benefits of OOP. A need exists for 
these principles of OOP to be ^lied to a messaging interface of an electronic 
mess^jng system such fbst a set of OOP classes and objects for the messaging 
interface can be provided. 

10 

OOP is a process of developing compute software iising objects, including the steps 
of analyzing the problem, designing the system, and constructing the program. An 
object is a software package ^ contams boA data and a coDection of relate 
stmctures and procedures. Since it contains bo& data and a collection of structures 

15 and procedures, it can be visualized as a self-sufficient component diat does not 
require other additional structures, procedures or data to perform its specific task. 
00P» therefore^ views a computer program as a collection of largely autonomous 
components, called objects, each of i^ch is responsible for a specific task. This 
concept of packag^ig data, structures, and procedures together in one component or 

20 module is called enc^sulation. 

hi g^eral,.OOP conqionents are reusable software modules whidi preset an 
interface that confozms to an obj ect model and which are accessed at run-time 
through a component integration architecture. A component integration architecture 

25 is a set of architecture mechanisms which allow software modules in difierent 

process qiaces to utilize each others capabilities or functions. This is generally done 
by assu mi ng a common component object model on which to build the architecture. 
It is worthwhile to differentiate between an object and a class of objects at this point 
An object is a single instance of the class of objects, which is often just called a 

30 class. A class of objects can be viewed as a blueprint, fiom which many objects can 
be formed 



OOP allows the programmer to create an object that is a part of another object For 
exanq)le» the object representing a piston engine is said to have a coiiq>osition- 
relationship with the object representing a piston. In reality, a piston engine 
con^rises a piston, valves and many other componoits; the &ct that a piston is an 
S element of a piston engine can be logically and semantically represented m OOF by 
two objects. 

OOP also allows creation of an object that "depends fiom" another object If there 
are two objects^ one representixig a piston engine and the other representing a piston 

10 engine wheiein the piston is made of c«:amic, ^len the reIationshq> between the two 
objecte is not that of cQn9>osition. A ceramic piston engine does not make itp a 
piston engine. Rather it is merely one kind of piston engine that has one more 
limitation Aan &e piston engfaie; its piston is made of ceramic Jn this case, the 
object representing the ceramic piston engine is called a derived object, and it 

1 5 inherits all of the aspects of the object representing the piston engine and adds 
furdier limitation or detail to it Hie object representing the ceramic piston engine 
"depmds from" the object rq>resratmg the piston engine. The relationship between 
tliese objects is called inheritance. 

20 When die object or class representing the ceramic piston engme inherits all of the 
aspects of the objects representing the piston engine, it inh^ts the thermal 
charactenstics of a standard piston defined in the piston ^gme class. However, the 
ceramic piston engine object ovmides these ceramic specific thermal characteiisdcs, 
wbidk are typically differait jSx>m those associated with a metal pistoiL It skips over 

25 Aeorignial and uses new fimctions related to ceramic pistons. DifTermt kinds of 
piston oKgjnes have different characteristics, but may have the same mideriying 
functions associated widi it (e.g., how many pistons in the engine, ignition 
sequences, lubrication, etc.). To access each of these functions in any piston engine 
object, a programmer would call the same functions with the same names, but each 

30 type of piston engine may have different/oveniding implementations of functions 
bdiind the same name. This ability to hide different implementations of a fimction 



belund the same name is caQed polymoiphism and it greatly simplifies 
commumcatioii among objects. 

With Ifae concepts of composition-relationship^ encapsulation, inheritance and 
5 polymoiphism^anobjectcanrepresentjust about anything in the real wo Ih&ct» 
one's logical perception of the reality is the only limit on determining the kinds of 
fhmgs that can become objects in object-oriented software. Some typical categories 
are as follows: 

• Objects can represent physical objects, such as automobiles in a trafSc-flow 
10 simulation, electrical conoqponents in a circuitnlesign program, countries in an 

economics model, or aircraft in an air-tra£Gc^ntrol system. 

• Objects can represent elements of the computer-user environment such as 
windows, menus or gr^hics objects. 

• An object can represent an inventory, such as a persomiel file or a table of the 
1 5 latitudes and l(Higitudes of cities. 

• An object can represent user-defined data types such as tnne, angles, and 
complex numbers, or points on tiie plane. 

With this enormous capability of an object to r^rosent just about any logically 
20 sq>arable matters, OOP allows flie software developer to design and implement a 
computer program that is a model of some aspects of reality, whether that reality is a 
physical entity, a process, a system, or a composition of matter. Since the object can 
r^resent anything, the software developer can create an object which can be used as 
a component in a larger software project in the future. 

25. 

If 90% of a new OOP software program condsts of proven, existing components 
made fit>m preexisting reusable objects, Oien only the remaining 10% of the new 
software project has to be written and tested from scratch. Since 90% already came 
from an inventory of extensively tested reusable objects, the potential domain firom 
30 which an error could c»iginate is 10% of the program. As a result, OOP enables 
software develops to build objects out of other, previously built objects. 



This process closely resembles complex machinety beisg built out of assemblies and 
sub-assemblies. OOP tedmology, therefore, makes software engineerm 
hardware engineering in that software is built from existing components, which aie 
5 available to the developer as objects. All this adds iq> to an improved quaUty of the 
software as well as an increased speed of its development. 

Programming languages are beginning to fidly support the OOP prmciples, such as 
encapsulation, inhetitance, polymorphism, and composition-relationsbip. With the 

10 advent of the C-h- language, many commercial software developers have embraced 
OOP. C++is8nOOPlangaagethatof^afi5t,machin&^ecutablecode. 
Furthennore, C++ is suitable for both commercial-plication and systms- 
programming projects. For now, C++ appesas to be the most popular choice among 
many OOP progranuners, but there is a host of other OOP languages, such as 

15 SmalltaD^ Common lisp Object System (CLOS), and Eiffel. Additionally, OOP 
capabilities are being added to more traditional popular computer programming 
languages such as Pascal. 



The benefits of object classes can be summarized, as follows: 
20 • Objects and their corresponding classes break down complex programming 
problems into many smaUer, simpler problems. 

• Enc^sulation enforces data abstraction through the organization of data into 
small, independent objects that can communicate with each o&er. 
Encq)suIation protects the data in an object ft^om accidental damage^ but 

25 allows other objects to interact with Uiat data by calling the object's member 

functions and stmctures. 

• Subclassing and inheritance make it possible to extend and modify objects 
through deriving new kinds of objects from &e standard classes available in 
the sj^em. Thus, new capabilities are created without having to start from 

30 scratch. 



• Polymozphism and multiple bheritance make it possible for difTerent 
progranuners to mix and match characteristics of many differeat classes and 
create specialized objects that can still wojk with related objects in 
predictable ways. 

• Class faierardiies and containment faieFarchies provide a flexible mechanism 
for modeling real-world objects and the relationships among them. 

• libraries of reusable classes are useful in many situaticms, but they also have 
some limitations. For example: 

• Compte3City. la a coiiq)lexsystan, the class hioardues for rdated classes 
can become extremely confusing^ mSx many dozeaos or even hundreds of 
classy 

• Flow of control A program written with the aid of class libraries is still 
responsible for Oe flow of control ^e., it must control the int^actions 
among all the objects created from a particular library). Ihe programmer has 
to decide vMdt functions to call at what times for which kinds of objects. 

• Duplication of effort. Although class libnriesaUdw programmers to use and 
reuse many small pieces of code, each programmer puts those pieces together 
in a different way. Two different programmers can use the same set of class 
libraries to write two programs that do exactly the same thing but whose 
internal stmcture (i.e., design) may be quite different, dependmg on hundreds 
of small decisions each programmer makes along the way. Bievitably, 
similar pieces of code end up doing similar things in slightly different ways 
and do not woik as well tog^er as diey should. 

Class libraries are very flexible; As programs grow more contplex» more 
progr ammers are forced to reinvent basic solutions to basic problems over and ov^ 
again. A relatively new extension of Qie class library concq)t is to have a fiamewoik 
of class libraries. This fiamework is more complex and consists of significant 
coUections of collaborating classes that c^ture both the small scale patterns and 
major mechanisms that implement the common requirements and design in a 
specific application domain. They were first developed to free qyplication 



programmers firom the chores involved iu displaying menus, windows, dialog boxes, 
and othCT standard user interface el^ents for personal computers. 

Frameworks also represent a change in the way programmers think about the 
5 interaction between the code they write and code written by others, hi the early days 
of procedural programming, the programmer called libraries provided by the 
operating sj^tem to perform certain tasks, but basically the program executed down 
the page fiom start to finish, and the programmer was solely responsible for the flow 
of controL This was ^propriate for printing out paychecks, calculating a 
10 mathematica] tatbl^ or solving otherproblems with aprogram that executed in just 
oneway. 

The development of graphical user intei£tces began to turn this procedural 
programnung arrangement inside out These inter&ces allow the user, rather than 

15 program logic, to drive the program and decide whm certain actions should be 

performed. Today, most persona] computer software acconq>lishes this by means of 
an event loop v^ch monitors the mouse, keyboard, and other sources of external 
events and calls the appropriate parts of the programmer's code according to actions 
that the user performs. Tlie programmer no longer determines the order in vMch 

20 eventsoccur. Instead, a program is divided into separate pieces that are called at 
unpredictable times and in an unpredictable order. By relinquishing control in this 
way to users, the developer creates a program that is much easi^ to use. 
Neverflieless, individual pieces of the program written by the developer still call 
hbraries provided by the operating system to accompli^ oertam tasks, and &e 

25 programmer must still determine the flow of control within each piece afier it*s 
called by the evCTt loop. AH>lication code still "dts on top or the system. 

Even event loop programs require programmers to write a lot of code that should not 
need to be written separately for every application. The concept of an application 
30 fiamework carries the event loop concept further, histeadofdealihg with all the 
nuts and bolts of constructing basic menus, windows^ and dialog boxes and then 
making these things all work togeth^, programmers using qiplication firamewoiks 



start with woiking ^plication code and Wic user interface elements in place. 
Subsequ^y, they build from there by repladng some of the generic c^abilities of 
the firamewoik wiQi tiie specific cq)abilities of the intended ^plication. 



S Application fiamewodcs reduce the total amount of code that a programmer has to 
write from scratch. However, because the framework is really a generic explication 
that displays windows* supports copy and paste, and so on, the progranuner can also 
relinqmsh control to a greats degree than event loop programs permit The 
framework code takes care of almost all event handling and flow of control, and the 
10 programmer's code is caDed only when the framework needs it (e*&, to create or 
manipulate a proprietary data structure). 

A programmer writing a framework program not only relinquishes control to tiie 
user (as is also true fi)r event loop programs), but also relinquishes the detailed flow 
15 ofcontrolwidiin deprogram to the framewodc This ^proach allows the creation 
of more complex systems that work together in intmsting ways, as opposed to 
isolated programs, having custom code, beir!g created over and over again for similar 
problems. 

20 Thus, as is explained above, a framework basically is a collection of cooperating 
classes that make up a reusable design solution for a given problem domain. It 
typically includes objects that provide default behavior (e.g^ for meaxta and 
wiiulows), and programmers use it by inheriting some of that de&ult behavior and 
overriding othsr behavior so that flie framework calls plication code at the 

25 appropriate times. 

There are three main difierences betwe^ frameworks and class libraries: 
• Behavior versus protocol. GasshTnaries are essoatially collections of 

behaviors that you can call when you want fbost individual behaviors in your 
30 prograuL A framework, on the other hand, provides not only behavior but 

also the protocol or set of rules that govern the ways in which behaviors can 



be combined, including niles for what a piogranmier is supposed to provide 
versus what Qie fiamework provides. 

• Call versus ovenide. With a class binary, the code the programmer 
instantiates objects and calls their member functions. It's possible to 
instantiate and call objects in the same way with a framework (ix., to treat 
the JGramewodc as a class library^ but to take full advantage of a framework's 
reusable desigp, a programmer typically writes code that ovorides and is 
called by the framework. The framework manages the jQow of control among 
its objects. Writing a program involves dividing responsibilities among the 
various pieces of sofbA^are that are called by the framework ra&er tiian 
specifying how the difTerent pieces should work togeOier. 

• hnplementation versus design. Widi class libraries, progranuners reuse only 
implementations, miiereas with frameworks^ they reuse design. A framework 
embodies the way a fimilyofrdated programs <»* pieces of software woik. It 
represents a generic design solution that can be adapted to a variety of 
specific problems in a given domairu For example, a single framework can 
embody the way a us^ inter&ce works, even though two different user 
interfaces created wilfa the same framework might solve quite different 
interface problems. 

Thus, through the development of frameworks for solutions to various problems and 
programming tasks, significant reductions in die design and development effort for 
software can be achieved. A preferred embodiment of tiie invention utilizes 
HyperText Markup Language (HTML) to inq>lement documents on the Internet 
together with a general-purpose secure ccmmunicatian protocol for a transport 
medium between the client and the Newco. HTTP or other protocols could be 
readily substituted for HTML without uridueexperimcntatiorL Information on diese 
products is available in T. Bemas-Lee, D. Connoly, "RFC 1866: Hypertext Markup 
Language - 2,0" (Nov. 1995); and R. Fielding. H, Fryst)k, T, Bamers-Lee, J. Get^ 
and J.C. Mogul, "Hypertext Transfer Protocol - HTTP/l.l: HTTP Workbg Qioup 
Meroet Draft'' (May 2, 1996). HTML is a sinqile data format used to create 
hypertext documents that are portable fiom one platform to anoflier. HTML 



documents are SGML dcx;mn^ts with generic semantics that are appropriate for 
rq)resentmgMormationfi:oin a wide range of domains. HTML has been in use by 
the World-Wide Web global information initiative since 1990. HTML is an 
qjplication of ISO Standard 8879; 1986 Monnation Processing Text and OfBce 
5 Systems; Standard Goieralized Madcap Language (SGML). 

To date, Web development tools have been limited in their ability to create dynamic 
Web applications which span fiom client to server and int^perate with eidstii^ 
computing resources. Until recently, HTML has been the dominant technology used 
10 ra development of Web-based solutions. However, HTML has proven to be 
inadequate in the following areas: 

• Poor performance 

• Restricted user interface c^abilitie^ 

• Can only produce static Web pages; 

15 • Lack of interoperability with existing applications and data; and 

• Inability to scale. 

Sun Nficroqrstem's Java language solves many of the client-side problems by: 

• hnproving performance on the client side; 

20 • Enabling the creation of dynamic, real-time Web application^ and 

• Providing flie ability to create a wide variety of user interfece components. 

With Java, developers can create robust User Interface (UI) components. Custom 
'Nvidgets'* (e.g.3 real-time stock tickers, animated icons, etc.) can be seated, and 
25 cUmt-sideperfoimance is improved. Unlike HTML^ Java supports the notion of 
client-side validation^ ofQoadtng appropriate processing onto the client for ]nq>rov6d 
perfonnanca Dynamic, real-time Web pages can be created. Using die above- 
mentioned custom m components, dynamic Web pages can also be created. 



30 Sun*s Java language has emerged as an industiy-recognized language for 

"programming the Internet." Sun defines Java as; "a sunple» object-oriented. 
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distributed, interpreted, robust, secure, architecture-neutral, portable, high* 
performance, muhitbreaded, dynamic, buzzwoid-compliatit, general-pinpose 
programming language. Java supports programming for the btemet in tfie form of 
platform-independent Java ^plets." Java applets are small, specialized ^plications 
5 that comply with Sun's Java Application Programming loter&ce (API) allowing 
developers to add ''interactive content*' to Web docmn^ts (e.g., simple animations, 
page adonnnents, basic games» ^c.)- Applets execute within a Java-compatible 
browser (e,g^ Netscape Navigator) by copying code ftom the s^er to cUent From 
a language standpoint; Java's core feature set is based on C-H-. Sun's Java literature 
10 states that Java is basically, **C++ with extensions from Objective C for more 
dynanuc method resolution.*' 

Another technology fbat provides similar function to JAVA is provided by Mcrosoft 
and ActiveX Technologies, to give developCTS and Web designs wherewithal to 

IS build dynamic cont^t for the Ihtemet and personal computers. ActiveX includes 
tools for developing animation, 3-D virtual reality, video and otha- multimedia 
content The tools use btemet standards, woik on multiple platfoims, and are being 
supported by over 100 companies. The group's building blocks are called ActiveX 
Controls, small, fast components that enable developers to embed parts of software 

20 in hypertext markup language (HTML) pages. ActiveX Controls woik with a variety 
of programming languages including Microsoft Visual C++, Borland Delphi, 
Microsoft Visual Basic programming system and, in the future, Microsoft's 
development tool for Java, code named "Jakarta." ActiveX Technologies ako 
includes ActiveX Server Framework, allowing developers to create server 

25 applications. Qneofordinaryskillinlfaeart readily recognizes that ActiveX could 
be substituted for JAVA wi&out undue experimentation to practice die inv^on. 

Syncbronlzatfon Overview 

30 Figure 2 illustrates a flowchart delineating a method for synchronizing an event on a 
plurality of clifflt apparatuses. Firs^ in operation 200, an event is stored in memory 
on at least one of the cli^t apparatuses. In various embodiments, the memory may 



take the form of an electromagnetic medium, or any type of optical storage device; 
i.e. CD-audio. In a primary aspect of the present invention^ Hit memory includes a 
digital video disc (DVD) (audio or video). Fuither^ for reasons that will soon 
become apparmt, tbe informatioa includes chq>ter information associated with the 
S DVD. In such embodiment whm the memory is portable, the usCT may be required 
to pm:chase the memoryt i,e. DVD, in order to participate in a synchronized event» 
thus increasing the sale of DVD's. 

It should be noted diat the ev^need not be necessarily stored in memory on all of 
10 the client apparatiKes, but rather stored on one or some of the chent apparatuses and 
streamed to the remaining client ^aratuses at ^^uiarit rates. This may be feasibly 
accomplished if the client ^pparatus(es) containing the stored event has a high- 
bandwiddi connection wrfli the remaining cliait apparatuses* For example, the client 
apparatus(es) containing the stored event m^ include a server that has a connection 
15 to a phirality of televisions via a cable networ}^ i.e. WEBTV. Similar fimctionahty 
may be achieved via a broadcast medium. The present invention is thus flexible by 
having an ability to host user events and corporative events. 

In one ^bodtment, the event includes a video and audio presentation such as 
20 movie, a concert, and/or a theatrical ev^t. It should be noted, however, that the 
event may included any recording capable of being played back for ent^taiimient, 
education, informative or other similar purposes. 

hi use, the client a^aratuses and a host compute are adq)ted to be connected to a 
25 network. Such network may include a wide, local or any other type of 

cormnunication network. For example, a wide area network such as the lotemet may 
be employed which opemtes using TCP/IP or IPX protocols. 

In operation 202, information is transmitted &ota the host computer to the 
30 appropriate client apparatuses utilizing the netvtrork. This information allows for the 
simultaneous and synchronous pl^ack of the event on each of the client 
apparatuses, hi one embodiment, the information may also include a start time when 
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the playback of the event is to begin on each of the cUent apparatuses. Further, an 
ending time may be included when the playback of the event is to end on each of the 
client apparatus^. Still yet, "pla/* command infonnation may be sent to the client 
apparatuses at the start tima As an option, input may be received from the user, and 
5 used to alter the playback of the event The host server, or synchronization server, 
can also control various streams of a variant rate and difier^ hardware associated 
widi those streams^ 

The preset invention thus has fte abiH^ to synchronize video playback for one or 
10 multqple (diousands) users from one or multiple physical locations, and to 
synchronize witii external video, audio and/or data streams. 

Users of the preset invention are at multiple pfa^cal locations and host servers 
may also be at different locations. The present inv^tion is thus a scalable system 
15 which is capable of servicing an imlimited number of users. Since the content is 
local to the user machine, no high network bandwidth is required 

Historv Download Capabilities 

20 Figure 3 illustrates a flowchart delineating a method for storing synchronization 
injfomation for subsequent playback of an event Initially, in operation 300, an 
event is stored in memory on at least one of the client ^paratuses, as set forth 
earlier. These client ^paratuses are adapted to be connected to a n^ork along 
with a host computer during use. 

25 

In operation 302, information is stored on the host oomputeir(s) for allowing the 
simultaneous playback of the ev^t on each of the client apparatuses. In one 
embodiment, the information may include a history and data associated with the 
synchronous playback. Inparticular, the history may include any overlaid 
30 material(as will be described ha:einafier in greater detail), any specijSc commands 
affecting the playback of the information, or any other type of general information, 
i.e. start time, end time, etc. 
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Jin operation 304, the infonnatioii may be downloaded utilizing the netwoik at wy 
time after fhe synchronous playback of the event Such downloaded mformation 
may then be used for playback after the simultaneous playback of the event As 
S such» the present inv^tion has the ability to allow users to download a histoiy and 
data associated with a particular synchronization event and play it later. 

Ov^lav Svncfaronization 

10 Figure 4 ilhistrates a flowchart settmg fordi a method for providing overlays during a 
synchronized event on a plurality ofcliGotq)paratase3 or any other sonr^ Krst^in 
operation 400, a plurality of client apparatuses are connected via a network. In 
operation 402, an ^CTt may be shnultaneously plff/ed back on the client apparatuses 
utilizmg the network, as s^ forth eailier. 

15 

During the playbadc of the event, visual and/or audio materia] may also be overlaid 
on the event based on input received from at least one of the cli^ apparatuses. See 
operation 404. This may be accomplished by fransmittmg the overlay material fiom 
one of the chent ^paratuses to the host computer or any odier server, and 
20 multicasting the same to the remaining client apparatuses. 

As an option, the overlay material may include annotations on a display of the client 
^paratus. For exaniple, the overlay material may include sketches which are 
inputted by way of a st^his-based mput screen or a keyboard or the like, along with a 
25 voiceover uqnitted by way of a mic^phone or voice synthesizer. Such c^abihty 
may also be quite vahiable in an educational enviioimient 

In one embodiment the overlay material may also be displayed on each of the client 
apparatuses utilizing the network. This allows each of the users to experience the 
30 overtay in real-time during the simultaneous playback of the event As an option, 
the user inputting the overiay material may select which useis may exp^ence the 
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overlay material. The client ^arabis that provided the overlay material may also 
be identified to the users experiencing the overlay material. 

Jt should be noted that various bi-diiectional communication may be enabled for 
5 allowing data to travel to and from the server. For instance^ the playback of the event on 
the client apparatuses may be altered in any feasible way based on input from a user. 

Late Svnchrom2ation 

10 Figure 5 illustrates a flow diagram for delayed synchronization of an evest on a 
plurality of client f^paratttses. First, in operation 500» a plurality of cMent 
apparatuses are connected via a network and an event is stored in memory on &e 
client ^paratuses. The event is then simultaneously pl^ed back on the client 
^aratuses utilizmg the network, as set forth earlier. Note operation 502, 

15 

During the simultaneous pl^ack, a request m^ be received from one of the client 
apparatuses for that particular to be included in the synchronized event, as set forfh 
inopcxationSfM. This request may be received after the synchronized event has 
already begun while it is still playing- Further, the request may be submitted via a 
20 site on a network, i.e. website. 

hi response to the request, information is transmitted in operation 506 to the 
requesting client i^paratus utilizing the network. This information is ad^ted for 
idCTti^ong a location in the memory where the evoit is currently being played back. 
25 This aOows the simultaneous playbadcofthe event on the requesting client 
apparatus. 

The end users are thus able to come m at a later time and to be synchronized with the 
event Targeted synchronization and various filters crit^a can be apphed to target 
30 different audiences. Also language and cultural difTer^es can be taken into 

account. Still yet, the present invention may be adapted to address usors on difTexent 
hardware platforms (MAC, PC, set-top boxes). This may be acconq)lished by 
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identifying the iiser using a cookie, a Viser profile which is identified by way of a log 
in, or a Bum Cut Area (BCA) of the disc 

An example setting forth details relating to identifying DVDs will now be set forth* 
5 First, a content owner (such as studio) requests use of the BCA on their DVDs. Based 
on request, the replicator (examples include WAMO, Panasonic, Nimbus, Technicolor, 
Pioneer, Qest) adds uniqae BCA number to evory DVD, Adding BCA number to each 
DVD requires a spedal (YAG) las^. This maybe the very last stqp in the 
manufacturing process. The BCA ntmibers for a specific DVD must then be entered 
10 into IhteiActual's BCA databaseL iiformation to track inchides: DVD tifle, i.e- "Lost in 
Space"; BCA Wrmg^ Le. 12345687890; and Shipping Packaging/Traddng Container, 
i.e. Box 52221 to Hollywood Video. 

After the BCA number is added to the DVDs, the DVDs are packagin^oxed for 
15 distribution to eithor the Distributor or the Retailer. It should be noted that many 
companies take multiple fonns, so the replicator and distributor may be one in the 
same. Also, some retailers are large^portant enough to get shipm^ts directly 
fiom replicator. The way in which the DVDs are packa^g^shipped is very 
impcHtant because one must track the BCA numbers to actual shipping containers 
20 (box, etc.). Therefore tracking information must also be added to the BCA database. 

If packaged DVDs are then s^t to distributor, the distributor also has mechanisms, 
i.e. scanners, ir^ut device, and monitoring devices, in place for tracking based on 
their distribution. For example:, Deluxe may receive a 'package" of 100,000 copies 
25 of 'Xost in Spacer" However, the distributor ships 10,000 to Retailer A and 5,000 to 
Retailer B. The distributor should be able to 'iriput" r^ler A and B's distribution 
information into the systent Ideally, tins becomes a seamless/automated process. 

Once the DVDs reach flie r^er (eithor fix>m tiie replicator or distributor), flien 
30 DVDs may be forther divided and distributed to local stores/outlets. In such a 
situation, the retailer should be able to automatically 'track" distribution of these 
DVDs through to their stores. Over time^ all three entitities (replicator, distributor. 



and retailer) are able to add tracking in&nnation to BCA database. Due to 
contplexity and depoid^des on existing business systems, tbe retail tracking 
concept will be rolled out in phases: rq)licator first most likely wifb key retail 
accounts. The distributors will be bron^t in. Retailers will then begin to embrace 
S the ability to track based on local outlet/store. 

By the foregoing design, easy dq>loyment is Hm afforded and mimmal hardware is 
required to allow the synchronization of content without significant cq)ital 
investments and with a very efSdent control mechanism. The content delivery does 
10 not rely on higji netwoik bandwidth and is independent 6om tibe syndnonization. 

Memet Server Application Program Interface (KAPI) extensions will be used on the 
server. ISAPI extoasions provide a Tnehhanigm fn TnamtHi'n y mporftty or 
pemoanent connection with the users. These connections allow the Synchronization 
15 Server to process request and to send the appiopiiate DVD coininands. The 

permanent connections are known as *Xeep AM ve" connections, ISAPI extension 
can also b e used as an HTTP intei&ce to a more traditional searver, wifli all data 
returned as text 

20 On the client side the approach is to use, but not limited to Java 1 . 1 applets, to 
initiate event start-up for the Synchronization server. The advantage of using Java 
LI applets is to achieve platform independence for existing and future Java-enabled 
devices. JavaScript will be used to provide user interface navigation by '*wiB|>pmg" 
the applet. 

25 

An ISAPI (Internet Serv^ Application Program hiterfice) is a set of Windows 
program calls diat let one write a Web server plication that will run fiister than a 
Common Gateway bits&ce (CGB) ^plication. A disadvantage of a CGI plication 
(or "executable file," as it is sometimes calle<0 is that each time it is run, it runs as a 
30 sqjarate.process vwth its own address space, resulting in extra instructions that have 
to be performed, especially if many instances of it are running on behalf of users. 



Using ISAPI, you create a Dynamic Link libraiy (DLL) application file that can run 
as part of the Hypertext Transport Protocol (HTTP) ^plication*s piocess and address 
space. The DLL files are loaded imofteconqjuter when HTIP is started and ren^ 
fhrare as long as lliey are needed; they dont have to be located and read into storage 
5 as fi:equently as a CGI plication. 

Existing CGI £pplications can be converted into K API application DLLs wifliout 
having to rewrite flieir logic. Howev^, they do need to be written to be tfaread-safe 
so that a single instance of fiie DLL can serve multiple users. 

A special kind of ISAPI DLL is called an ICS API filter, which can b e designated to 
10 receive control for evay HTTP request One can create an IS API filter for 

encryption or decryption, for logging, for request screening, or for other purposes. 

One can write ISAPI serv^ extension DLLs ^ISAs) that can be loaded and called by 
the HTTP server. Usears can fill out foims and click a submit button to send data to a 
15 Web server and invoke an ISA, which can process the information to provide custom 
content or store it in a database. Webster extensions can use infoimation in a 
database to build Web pages dynamically, and then send Ihem to the client 
computers to be displayed. An application can add other custom fimctionality and 
provide data to the client using HTTP and HTML. 

20 

One can write an ISAPI filter. Thefilt^isalsoaDLLthatrunsonanlSAPI- 
enabled HTTP server. The filter registers for notification of events such as logging 
on or URL mapping. When the sdected events occur, the filter is called, and one 
can monitor and change the data (on its way fiom the server to the client or vice 
25 versa). ISAPI filteis can be used to provide custom encryption or compression 
schemes, or additional authentication mefliods. 

Bodi server extensions and filters run in the process space of the Web servo*, 
providing an efficient way to extend the server's capabilities. 

30 

Overall Component Design 



The various functional components of the software associated with the present 
invention will now be set forth. Sudi componrats include a Java/JavaSraipt 
Component, Synchronizer Component, Layerlmpl Compon^t; Business Layer 
S Conotponent, Configuration Manage Compon^t, and DBConnect Component 

Java/JavaScript Component 

Figure 6 illustrates a flow diagram for providing information on a synchronized 
10 event on apturality of cHent apparatuses in accordance with one embodiment of the 
present invention. First; in operation 600, a plurality of client ^paratuses are 
connected via a network, as set forth earlier. Next, an plication program is 
embedded on a site on the n^woik in operation 602. Such ^Hcation program may 
take the form of a JAVA applet, and the site may include a website on the Internet. 

15 

Liuse, information is requested firom a server on the network utilizing the 
application progranL See operation 604. Such information relates to an event to be 
played back simuhaneously on the client apparatuses and may include general 
information such as a start and stop time of the event, or more specific information 
20 about the event itself. 

In re^onse to such request, a script is received for displaying the inftnrmatiorL Note 
operation 606. The script may take any form such as Perl, REXX (on IBM 
mainfiames), and Tcl/Tk, and preferably includes a JAVAsc^pt 

25 

In one embodiment of the presexxt invention, the JAVA ^plet may be further 
adq>ted to send a request to retrieve command information fiom the server for use 
with a playback device of one of die client ^aratuses. The commands may be 
adapted to pla^ack the event on the playback device simultaneous with the 
30 playback ofthe event on die remaining client apparatuses. Further, the commands 
may include a start time when the playback of the ev^t is to begin on each of the 
cfient s^paratuses. 
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Tbe JAVA applets and JAVAscript are used to conununicate wifli die pl^back device 
of die client apparatuses. Id one embodimeQ]^ the playback device inchides a 
PCFriwidly TM video play^ mamifectured by Meractual ®. 

5 

The Java applet is embedded within a web page and uses HTTP protocol to 
communicate to the synchronization s^er. The q^pl^ could request event 
infonnatim jSrom the server, and display it to the user via JavaScript The ^plet 
could also send a '^BroadcastVideoEvenf* request to retrieve DVD commands that 
10 can be passed to fte video component, as set forth hereinabove. 

Synchronizer Component 

Figure 7 ilhistrates a method for creatmg a synchnmizer object in order to playback 
IS an event simultaneously on a plurality of client apparatuses. The synchronizer object 
is portion of the software that actuaUy intplements the synchronization procedure. 
First, in operation 700, a request is received utilizing anetwoik for viewing an event 
Next, the request is queued in memory in operation 702. 

20 In response to the request, in operation 704, an object is CTcatcd which is adapted to 
playback the event on a client q)paratus simultaneous with flie playback of the event 
on tiie remaining client appamtuses upon the receipt of an activation signal. As an 
option, the activation signal may be provided using a clock of the client apparatus, or 
locate at a different location, i.e. server. To accomplish &is, the object identifies a 

25 start time when the playback of the event is to begin on each of the client 
apparatuses. 

In operation 706, the object is sent to one of the clirat apparatuses utilizing tbe 
network for being stored therein, hi accordance with a primary aspect of the present 
30 invention, the object may be adapted to playback die event which is stored in 

memory of &e client ^paratus. This may be accomplished by activating a digital 
video disc (DVD) player. 



In sununazy, when the SyachroBizer componeiit receives a '^BroadcastVideoEvenf* 
&om the q)plet, it then places die request in the thtead queue for processing. To 
process a request, the thread creates a "call back** object, if one does not exist for 
5 this event The thread then adds flie request to the "call back" object queue. This 
"call back** object will be invoked when it is time to play the DVD. The 
Synchronize con^nent creates a CaU Back CX)M object, X<9^^ The 
Synchronizer component is also responsible for creating the LayerFactory int»:jace 
which will be set forth heremafter in greater detail 

10 

Lawhnpl Component 

Figure 8 illustrates a flowchart for affordmg a scheduler object adapted to faciHtate 
the playback of an event simultaneously on a plurality of networked cH^t 
IS apparatuses. The present method ensures that critical information is tracked during 
the synchronization of the event Such critical infonnation not only ensures prop^ 
synchronization^ but also cables various perq)heral features. 

First, in operation 800, various values are detemiined including a current time, a 
20 start time wh^ an event is to start, aiui a stop time when the event is to end. 

Thereafter, a length of the event is calculated based on the start time and the stop 
time in operation 802. As an option, the current time is determined by queiying a 
clock of one of the clioit sqjparatuses. 

25 If any portion of the length of flie event takes place during a predetermined thi^hold 
period, a command is stored in memory in operation 804. The command may be 
adapted to automatically begin playing bade the event at the start time, inone 
^nbodiment, the threshold period includes the time the users can be queued before 
the evCTt As an option, chapter information may be stored in the m^ory if any 

30 portion of the length of the event takes place during the predetermined threshold 
period. This allows the command to automatically begin playing back the event at a 
predetenmned chapter. 



Business Layer Component 

Figure 9 is a flofwcbart delineating a method for identi^dng a plurality of events 
5 wUdbi are played bade simultaneously on a plurality of networked clie^^ 

Tiiis features is important since a host server may be synchFonizing more than one 
event at once» or duiing overlying times. Such events must therefore be 
distinguished. 

1 0 First, in operation 900, a plurality of events arc stored in memory on a plurality of 
client ^paratuses. Each of the events is assigned a unique identifier which is stored 
in the memory. 

In operation 902, the client qiparatuses are ad^ted to be coupled to a host computer 
IS via a netwod^ as set forth h^einabove. M operation 904, the identifier of the event 
which is stored in the memoiy of the client apparatuses is dien retrieved utiUzing the 
network. Such idratifier is subsequently conq)ared with an id^tifier of a scheduled 
event, as set forth in operation 906. If the comparison renders amatch, fiie playback 
of the event is begun on the appropriate client apparatuses. Note operation 908. 

20 

CbusinessLayer thus differentiates events by the disk and location ids, uploaded by 
the client to guarantee backwards compatibility. As set forth earlier, late arrivals can 
always re-sync with Ae ev^t 

25 Configuration Manager Component 

Figure 10 shows a flowdbart delineating a tedmique for identtj^ing playback devices 
of a plurality of client ^paratuses which are networked to shnultaneously playback 
an event The present technique is important since the playback devices of the 
30 various cUent apparatuses may differ in make and model. Thus, different commands 
are required fiierefor. 



la operation 806, a loop is created at the start time duiing which a lapsed time of the 
event is tradced. Tins information maybe used for various traddngpxurposes to 
decide \^en to issue commands to the user, b another embodiment, a second locp 
5 may be created upon the beginning of a chapter during which information on a next 
chapto- is retrieved. 

Hie "call back*' object {LayerSink) is thus responsible for creatmg and 
communicating with die Layerlmpl compon^ The Layerlmpl component acts as a 
10 scheduler^ detennining whm to issue connnands to the user. 

Layerlmpl will issue diflferent DVD commands, based on the type of decoder the 
user has in their PC. Ia)^/in/7/wiUdi%r^tiate between the decoders by usi^ 
decoder information submitted ficm flie client Hie Layerlmpl will pass the correct 
15 DVD command to the client, based on the decoder's ci^abilities. For example, if 
the decoder does not si^iport the TimePlay event, ihm the server may send a 
ChapterPlay event and wait appropriately. 

The following is an enumemted summary of the steps the component uses to 
20 deteraiine vdien the users will receive the DVD commands: 

1. Retrieves the currmt time, and the time the event starts and ends. 

2. Calculates the length of the event 

3. If the event is within a threshold period (Le. the time users can be queued before 
25 the event), then store the first DVD command in memory. Also, store the Ch^t^ 

infonnation in memoiy. 

4. Qreate a loop Aat processes request until the ev^ has conq)leted. 

5. ia the loop, calculate the lapsed time of the event 

6. In the loop, retrieve the next cfaq)t^ infonnation. 

30 7. Create another loop that will loop until time for the next chapt^ to be played. 

8. When the next ch^ter is ready to play, send the command that was retrieved from 
the Chapt^ table. 



In operation 1000, a type of the playback devices of the client ^azatuses is first 
identifiecL Such ^'type^' may lefo to a make., model, or aiQ^ other di 
cbaractmstic of the particular playback devices. A command associated with the 
identified type of the playback device is then looked up in a look-up table. Note 
5 opesration 1002. Such table maybe located at the host server, or at any odier location 
sudi as the clieiit apparatuses. 

Thereafter, in operation 1004, tiie conunand is sent to the corresponding client 
apparatus for beginning the playback of the event simultaneously with Ae playback 
10 ofthe event on each ofdie remaining client ^yparatuses. 

This conq)oneat is thus responsible for identifying what t^e of reference player is 
hostingtheev^ The reference player can be the database, which contains the 
DVD commands or a real trnie player. When the initial DVD is command is 
15 requested, die '"Synchronize]:'' table is queried fi>r the host type. From that pomt 
forward, the scheduler would know 6om whom to receive data. 

DBConnect Component 

20 This component is responsible for conununicating with the Synchronizer tables, and 
for providing access methods for the retrieved data. All interaction fi:om the tables is 
on a read-only basis. The Layerlmpl component communicate with this compon^t 
to retrieve DVD commands and event information. 

2S Even though current tnylemcntation may be based on a IvficFosoft platform, hard 
dependencies on Microsoft or any other 3rd-^ar^ development tools may be 
avoided. To address such issues, the following consid^ntions may be made 
throughout the code: 

30 MFC specific code mayr be avoided. histead,STLmaybeused. ATL and/or MFC 
code may be encapsulated into separate classes and portioned fiom the rest of the 
code. Class implementations may use aggregation pattern to delegate business logic 




to file portable classes. Database connection classes may be separated and the 
communication protocol may be sqmrated with respect to portability to Oracle and 
other platforms. 

5 Figures 11 and 12 illustrate die order of events among the various components of the 
present inventioiL hi particolar. Figure 11 illustrates the manner in which a layer 
&ctory is created As shown, an event is first checked in a database server after 
which a business layer is cre^ed in a WEB s^er in a manner set jfoith heieimtbove. 
The forcing conq>onents are then created Figure 12 illustrates the manner m 
10 vMdi user requests are processed As shown, communication is afforded with the 
video playw on the client machine by means of JAVAscript and JAVA applets. The 
WEB server, in turn, communicates DVD commands to the video player via the 
JAVA ^pletSy and also interfaces the database server via die various components 
thereof \^ch wm set forth herdnabove. 

15 

Alternate Embodiments 

To support fiiture enhancm^sts, &rfher components may be included with extendibility 
as the major objectiva Various future enhancements of the product and how they will 
20 be addressed will now be set forth. 

Hosted Real lime Flayers 

While spirals may retrieve pre-recorded DVD contunands 6om the database, 
25 alternate spirals may support a consumer as a host The architecture may also 

support plug-in cooiponents. Alternate spirals m^ support the RealTimeCdmiector 
component, which accepts host user request and forwards them to the clients. The 
instant architecture siqyports the DBConnector which accepts events fiom the 
database. 

30 

Keep Alive Connections 
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Clients may maintain corniecdons throughout the event This allows the host to send 
a various numb^ of conmiands to the client of event Although the spiral 
disconnects users once a PLAY command has been issued, Uie Synchronizer class 
(which will be set ferfh later) adds each connection to a Ihread Pool This pool of 
5 connections can be left open during the life of the event 

Logging Partimpants 

Each request may be logged into the database to provide a reference for the future. 

10 

DVD Positioning 

As an option, connections msy be pooled to allow the synchronization server to 
direct consum^^s machines to the certain locations thrcmg^out the entire event 

15 

Synchronization events in alternate spirals may be defined as a combination of play 
firom location event and the actual event This way, one d^cribes each event m the 
unambiguous way on the client side and synchrozuzes it with the server. For 
example, a situation may be considored where one &st forwards after a movie is 

20 played for IS min and thereafter plays the serein the movie. In such situation, one 
has to submit the information to the client player, indicating that it (plscyer) has to 
start time play fiom 15 min into the movie and fest-forward to the colain location. 
A better way would be to analyze y/bst is the next event after fast forwarding 
occurred and perform a combination for the play fiom location and next event This 

25 design would require significant chaiiges to die client infiastructure, including video 
object^ remoteagent and provider and should be taken into oonsidearation in any 
alternate client design. 

Classes/Component Dif^;rams 

30 

Figures 13-16 illustrate various class/component diagrams, in particular. Figures 13^ 
16 illustrate a Synchronizer Class Diagram 1300, Layerlmpl Class Diagram 1400, 



Business L^er Class Diagram 1500, and DBConnect Class Diagram 1600, 
respectively. 

Sequence Diagrams 

5 

Figure 17 illustrates a logical sequence diagram 1 700. As shown, when the server 
receives a user request, it analyzes the auth^ttcation information of the request 
(date/thne, disc id, user id, and BCA number) and the ^pjiropriate syiudnonization 
event stored in the database. ThedatabasecontainsaneveRfj/aTt/AresAD/tf value 
10 measured in milliseconds. This tiireshold defines die amount of time prior to an 
event that a consumer is eligible to '•connect" for the start of flie event 

If the date/time of the user request lies within the event start thx^old, the user is put 
into wait queue and receive the ^ropriate data when the time elqises. Note steps 
15 1,2,3,5,6,7 ofthe Logical Sequoice diagram. Otherwise, a message is sent 

informing the user when the event will occur. Note step 4 of the Logical Sequence 
diagram. 

- Server side collaboration diagram 

20 

Figure 18 illustrates a logical sequence diagram 1800 that shows server side 
collaboration. As shown, server ISAPI ©ctension receives a BioadcastVideoEvents 
request. It calls M_Busine5sServervi^BeginProcess, to retrieve configuration 
information. Cozifiguration information contains a playback connector. Playback 
25 coimector identifies whether the server will have to communicate with a referaice 
plsy^ or will it poibrm pl^ack jGrom the database. 

At step 6, ISAPl extension will call IA_BusinessServer Compareltme method and 
based on the results will send to the user a predefined web page indicating to retry 
30 later or return control to the web server, notifying it (web server) to keep the 

connection open. At this point connection is pooled and will be processed by the 
i^^fusmes^^Slerver at a tone of the event 
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Client CoUaboration Diapram 

Figure 19 illustrates a logical sequence diagtam 1900 showing clieat side 
S collaboration in accordance with one embodiment of tiie present invention. 

Classes/bterlaces Definition 

Definitions of one embodiment of fte various classy associated widi the software wiiich 
10 izjq>l^ents the present invention wiQ now be forth. 

Class Appletl 
Purpose: 

15 

This is the class that inq)lement8 the applet The browser wiD use it to bootstr^ our 
^let 

Responsibilities: 

20 

» Request a BroadCastVideo event and to gather event status information. 
Collaborations: 
25 BroadCastEvent, CmEncrypt 

Base doss and implemented interfaces: 
Javax.Applet 

30 

Public interface: 



getChapter Returns the current chapter the reference player is playing. 
Return type: String 
Parameters: void 
Pre-conditions: None. 
5 Post-^nditions: None. 

getTidelnfo Returns the current title the refoence player is playing 
Retumtype: String 
Parameters: void 
10 Pre-conditions: None. 
Post-conditions: None. 

getStartTlme Returns the time Ae event is scheduled to start 
<SSA«M-JfflJ)DAlNDYYYV> 
I S Return type: String 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

20 getStartTimeSec Returns the time the event starts in seconds. 
R^um type: String 
Param^ers: void 
Pre-conditions: None. 
Post-conditions: None. 

25 

getStartTimeMinRetums the time the event starts in minutes. 
Return type: String 
Parameters: void 
Pre-conditions: None. 
30 Post-conditions: None. 



getStartnmeHrRetums lhe time the event starts in Hours. 
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Return type: String 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

5 

GetStartrimeDay Retams the time the event starts in days. 
Return type; String 
Parameters: void 
Pre-condition5: None. 
10 Post-conditions: None. 

GetStartTImeMntb Returns fiie time the event starts in months. 
Return Qfpe: String 
Parameters: void 
15 Pre-conditions: None. 
Post-conditions: None. 

GetStartTimeYr Returns the time the event starts in year. 
Return type: String 
20 Parameters: void 

Pre-conditions: None. 
Post-conditions: None. 

GetLenOfEvent Returns the length of the event. 
25 Return Qpe: String 
Parameters: void 
Pre-conditions; Nona 
Post-conditions': None. 

30 GetExpIredTime: Returns l^e time of the event 
Return type: String 
Parameters: void 



Prc-conditioiis: None. 
Post-conditions: None. 

getServeiTime: Returns tilie servers cuirent time <SSJ^ini:DDd^ 
5 Return type: String 
Paiameters: void 
Pre-conditions: None. 
Post-conditions: None. 

10 getServerTImeSec: Returns the severs cunrent in seconds. 
Return ^pe: String 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

getServerTimeMfai: Returns the servers current in minutes. 
Return type: String 
Parameters: void 
Pre-conditions: None. 
20 Post-conditions: None. 

getServerTimeHr: Returns the servers current in hours. 
Return type: String 
Parameters: void 
25 Pre-conditions: None. 
Post-conditions: None. 

gefierveiTbneiOay: R^ums the servers crareut in day. 
Return type: String 
30 Parameters: void 

Pre-conditions: Nona 
Post-conditions: None. 
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ge^erveiTimeMnth: Returns the servers cuirent in month. 
Return type: String 
Parameters: void 
S Pre^nditions: None. 
Post-conditions: None. 

getServeiThneYr: Returns the servers cmrait in year. 
Returnee: String 
10 Parametm: void 

Pre-conditions: None. 
Post-conditions: None. 

startProcr Calls tiie ISAPIs "SarverMb" method. 
IS Return type: void 

Parameters: String disk id. String location id 
Preconditions: None. 
Post-conditions: None. 

20 msgEvent: Calls BroadCastBvent applet 
Return type: void 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

25 

Class BroadCastBvent 
Purpose: 

30 This is the class that invokes the Synchronizer. 



Responsibilities: 



■ Sets the JavaScript with the command returned fiom the server. 
Collaborations: 

5 

CrriEiKarypt 

Base class and implemented interfaces: 
10 Java.Thread 

Class CDBConnect 
Purpose: 

15 

This is the class provides a public ict^&ce for components to request information 
fiom the DB tables. 

AesponsibilUies: 

20 

• Opens the database and Synchronizer, Ch^ter_Disk tables. 

■ Queries the Synchronizer by the specified disk id and location id* 

■ Queries the ChapterJMsk by disk id. 

" Provides the next chapter that is scheduled to pl^. 
25 ■ Queries the Decoder_Cq>abiUties table to detCTme if the requested pla^ 
time or chs^ter play. 

Collaborations: 

30 DBSyncSet 

DBReferenceSet 
CDBChq)terSet 



CDecoderCapabilities 

Base class and implemented interfaces: 

5 Public interface: 

GetNextChapter: Returns the next chapter to play. 
Returnee: Stxing 

Parameters: long time^ long title, BSTR Chapter 
10 Pte-conditions: None. 
Post-conditions: None. 

chkEvent: Checks if an event i s scheduled for the disk and location id 
Retnm type: String 
15 Parametm: long time, long title, BSTR Chapter 
Pre^nditions: None. 
Post-conditions: None. 

getJnitialDVDCommand: Returns flie first DVD conmiand to play. 
20 Return type: String 
Parameters: BSTR& 
Pre-conditions: None. 
Post-conditioDs: None. 

25 getjieztDVDComniand: Returns the next DVD command to play. 
Return type: String 
Parameters: BSTR& 
Pre-conditions: None. 
Post-conditions: None. 

30 

decoderAiray : Returns an array of decoder types. 
Return type: String 



Parameters: long **, long ** 
Pre-coiididons! None. 
Post-conditions: None. 

5 Pass CCConfid>tJgrlmDl 

Purpose: 

This is the class provides a public inter&ce for componeats to determine the type of 
10 zeferoice player hosting the event 

Responsibilities: 

" Opens the database and Synchionizar, GhapterDidc tables. 
15 ■ Queries the Synchronizer by fhe specified disk id and location id. 
■ Stores the reference player type. 

Collaborations: 

20 CConfigMerRecSet 

Base class and implemented interfaces: 

Public interface: 

25 

get_hostType: Returns the reference player host type. 
Return type: String 
Parameters: short 
Pre-conditions: None. 
30 Post-conditions: None. 

aass threadFunctor 
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Purpose: 

This class provides a threading model that classes can use to derive. 

5 

Responsibilities: 

■ Calls &e CreateBvent fUnction, which opens a named or unnamed event 
objec. 

10 " Calls Jbeginthread» which creates a thread begins execution of a routine at 
5tart_address. The routine at start_address must use the cdecl calling 
convention and should have no r^um value. When tibe thread retums fix)m 
that routine, it is terminated automaticaUy* 

■ Calls the WaitForSing^eObject functicm, which checks the current state of the 
15 specified object If the object's state is nonsignaled, the calling thread liters 

an efficient wait state. 

■ Calls the Reseffivent function, \^*ich sets the state of the specified event 
object to nonsignaled. 

« The state of an ev^t object remains nonsignaled until it is explicitly set to 
20 signaled by the SetEvent or PulseEvent function. 

CollaboratioTis: 

CC6nfigMerRecSet 

25 

Base class and implemented interfaces: 

Public interface: 

30 start: Starts the thread. 
R^um type: void 
Parameters: void 



Pre-conditions: None. 

Post-^onditioBs: None. 

stop: Stops the thread Calls CIoseHandle for the thread and event 
5 Return type: void 
Parameters: void 

Pre-conditiQiis: None. 

Post-conditions: None. 

10 Qasgjsapithread 

Purpose: 

This creates an ISAPI thread. 

15 

Re^nsibiliiies: 

■ Adds a request to a vector. 

■ Creates the sink object 

20 * Stores the request into sink object. 

■ Sends the time information to JavaScript 

Collaborations: 

25 LayerSink 
factoiySink 

Base class and implemented interfaces: 

30 tbreadFunctor 



Public interface: 



addreqnest: Adds the request to its \recton 
Rrtumtype: void 
Parameteis: void 
5 Pre-conditions: Nona 
Post-conditions: None. 

gefBLayerlnfo: Responsible for getting information about the event 
Return type: void 
10 Parameteis: std:string&,std::string&> Cbt^ServerContext^ 
Pre-conditions: None. 
Post-conditions: None. 

Qass factorvSink 

15 

Purpose: 

Manages flie IayQ:Sink and businessLayeiProp objects. 
20 ResponsibilUies: 

■ Stores a layraSink object 

■ Returns the "businesssLayetProp" <Business Layer Properties> 

■ Creates flie "businessLayerProp'* <Business Layer stnicturO 

25 

Collaborations: 

Lay^ink 
businessLayerProp 

30 

Base class and implemented intetfaces: 



Public interface: 

constract: Stores a layerSink object.. 
Retain ^pe: void 
5 Parameteis: void 

Pre-conditioDs: None. 
Post-xondMons: None. 

notil^reateLayer : Responsible for creating a *1>usmessiLayerProp**. 
10 R^um^pe: void 

Parametacs: BSTR, BSTR, DATE, DATE, LONG 
Pre-conditions: NoncL 
Post-conditions: None. 

15 Class laverSinl^ 

Ptirpose: 

layerSink rqiresents a sinik inter&ce and stores a quaie of requests. It creates a 
20 connection point object 

This call bade object, aUows asynchronously processing. 

Responsibilities: 

25 ■ Acts as die client sink object 

■ Sends the results to the user 

■ Creates the *^usinessLayef* and makes it a connection point object. 
" Goses the users connection. 

■ Creates a Factory int«fece by calling "createFactory*'. 
30 ■ Creates a connection point for die &ctory. 

■ Stores the LayerSink in the FactoiySink object 



■ Creates a cozmecdon point (call back) by calling AtlAdvise, between the 
connection point container and the client sink object This allows the client 
toiecdveevoits. 

■ Calls the connectable objects "getSorverLayer". This method fires an event to 
5 the clients sink object. 

■ Create a business layer, 

■ Store the request in its vector. 

" Rdease&e Sink Object (client) 

• CaDs AflUnadvise to terminates the ability of die client to receive events. 

10 

Collaborations: 

Base doss and implemented interfaces: 
15 Public interface: 



constmct: Qeates a connection point 
Return ^pe: void 
Parameters: void 
20 Pre-conditions: None. 
Post-conditions: None. 



addReqaest: Adds the request to its vector. 
Retomtype: void 
25 Parameters: BSTR, BSTR, DATE, DATE, LONG 
Pre-conditions: None. 
Post-conditions: None. 

createBnsinessLayer: Creates a business layer. Create the connection point . 
30 Return type: void 

Parameters: businessLayeiProp & 
Pre-conditions: None. 
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Post-conditions: None. 

updat^me: This can back function translates the time and sends the command to 
the user. 
5 Return type: void 
Parameteis: long,long 
Preconditions: None, 
Post-conditions: None. 

10 Qass CBusinessLaver 

PUfpose: 

Creates a layer&read object This object is responsible for providing access methods, 
IS which provide event information. 

Respomibilities: 

■ The "Synchronizers" createBostnessLayer method creates a class object from 
20 file "IBusinessLayer" interfece. <rhe class object is part of the Layerhnpl 

projects 

■ The BusinesLayers class object <m Jlayer> calls its "hiitialize" mefliod. 
<Note: mjilayer is the connection point object It identifies the "Sink 
£iter&^*'. 

25 " It then calls fte "initialize*' method ofthe connection point 

■ The Initialize" mefliod then calls the "ChkValidEvent" mefliod, which flien 
creates a layerthread object 

Collaborations: 

30 

CBnsinessLayer 
lay^thread 
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Base doss and implemented interfaces: 
Public interface: 

5 

Initialize: Calls Ifae ''OikValidEvoit'* method whidi kicks of a layer thread* 
Return Qpe: void 
Parameters: void 
Pre-conditions: None. 
10 Post-conditions: None. 

Qass lavertfaread 

Purpose: 

15 

This object acts as a scheduler, processing request fix>m its queue. 

Responsibilities: 

20 " Send DVD commands to the user, 

■ "Syncs" up late comers to the events. 

Collaborations: 

25 CBusinessLayer 
CDBConnect 

Base doss and implemented interfaces: 

30 Public interface: 

startThread: Processes requests fiom the queue 



Return ^e: void 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

5 

Qass CLaverFactorv 
Purpose: 

10 This otject manages tmsinesslayer objects. Business layer objects communicate with 
the reference player and notify the user which DVD conunand to play. 

Responsibiliiies: 

Send DVD commands to the us^. 
*^yncs" up late comers to die events. 
This object Implements the IID_LayerFactoiy interface. 
This COM object is the servers Comxectable Point object. 
This SCTver object supports connections to smk interfaces. These sink 
inter&ces reside on the client side and are equivalent to the "call back" 
fimctions in Windows. 

Collaborations: 

25 CBusmessLacyer 
CDBConnect 

Base class and implemented interfaces: 

30 Public interface: 
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getServerLayer 'Tiies" an event to create a business kyer with the properties 
reeved from the pipe object 
Returnee: void 
Parameters: void 
5 Pre-conditions: None. 
Post-conditions: None. 

piit_setjayer: call Hxe "CLayerFactotyhnpr addQ method. Supplyfag the 
"businesslayer" object 
10 This will added to shared mesnoiy queue and writt^ to a file. 
Return Qpe: void 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

15 

FlnaiConstnict: Calls the "CLqwFactoryfinpr FinalConstnict COM class object 
Retumtype: void 
Paramet^s: void 
Pre-conditions: None. 
20 Post-conditions: None. 

Although only a few embodiments of the present invention have been described in 
detail hereiny it should be understood that the present invention may be enibodied in 
many other q>ecific fbnns without dq>axting from the spirit or scope of the 
25 invention. Therefore, the present examples and embodiments are to be coiisideared as 
illustrative and not restrictive^ and tihe invention is not to be limited to the details 
givCT herein, but may be modified within the scope of tfte appended claims. 




CLAIMS 

What is claimed is: 



1 1. Ameffu)d for identifymgplayback devices of apluraHty of cUentappa^ 

2 which are netwoiked to simultaneously playback an event, comprising fke 

3 steps o£ 

4 (a) id^tiigfnig a type of the playback device of each of the client apparatuses; 

5 (b) looking up a command associated with the identified type of the playback 

6 device; and 

7 (c) sending the conmiand to the corresponding cfientq>paratus for begins 

8 playback of the event simultaneously with the playback of the event on each 

9 of the remaining client qyparatuses. 

1 2. Amethod as recited in claim 1, wherein the event includes a video and audio 

2 presentation, 

1 3. A meQiod as recited in claim I, herein the type ofthe playback device is 

2 identified utilizing the n^ork. 

14. A method as recited in claim 1, wherein the network is a wide area network. 

1 5. A melhod as recited in claim 1» and further comprising the stq> of storing on 

2 the client apparatus an identifier of a host s^er that sent the command. 
1 

1 6. A method as redted in claim!, wherein (he memory includes a digital video 

2 disc(DVD)- 

1 7. A computer program embodied on a cornputer readable inedium for 

2 identifying playback devices of a plurality of client ^paratuses which are 

3 n^woiked to simultaneously playback an event, comprising: 




4 (a) a code segqient for identifyiiig a type of the playback detvice of each of the 

5 client spparatase^ 

6 (b) a code segment for looking iq) a oonmiand associated with (he identifi^ 

7 of the playback device; and 

8 (c) a code segment for sliding the conimand to the corresponding client 

9 apparatus for beginning the playback of the event simultaneously with the 
10 playback of the event on each of die remaining client ^q^paratoses. 

1 8. Aconq)UterprogFama5redtedincla£m7, wheieintheeventijKsludesaA^^ 

2 and audio presentation. 

1 9. A computer program as recited in claim 7, vtdierein the t>pe of the playback 

2 device is identified utilizipg Hiq networlL 

110, A conqjuter program as recited in claim 7, \riierein the network is a wide 
2 areanetw<nk. 

1 11. A computerprogram as recited in claim 7» and further conqnising a code 

2 segment for storing on the client apparatus an identifier of a host server that 

3 sent the command. 
1 

1 12. A conq>uter program as recited in claim 7, wherein the m^oiy includes a 

2 digital video disc (DVD). 

1 13. A system for idmtij^g playback devices of a plurality of client ^paratuses 

2 whidi are n^odced to simultaneously playback an event, conipristng: 

3 (a) logic for identi^dng a type of the playback device of each of the client 

4 apparatuses; 

5 (b) logic for looking up a command associated with the identified type of the 

6 playback device; and 



7 (c) logic for sending the command to the coires|>ondkgcUen^ 

8 b^ginziing the playback of the ev^t shnuitaneously with the playback of the 

9 event on each of fiie remaining client ^aratuses. 

1 14. A system as ledted in claim 13» wherein the event includes a video a^^ 

2 presentation. 

1 IS. A ^stem as recited in claim 13, wha:ein the type of the playback device is 

2 identified utilizing flienetwoik. 

1 16. A system as recited in claim 13, wherem the network is a wide area netwoik. 

1 17. A system as recited in claim 13, and fiiriher comprising logic for storm 

2 fte client q)paratus an identifier of a host servor that sent &6 commandL 

1 18. A system as redted in claim 13, wherein the niemoiy includes a digital video 

2 disc (DVD). 



SYSTEM, METHOD AND ARTICLE OF MANUFACTURE FOR A 
CONFIGURATION MANAGER COMPONENT IN A MULTIMEDIA 
SYNCHRONIZATION FRAMEWORK 



ABSTRACT 



A system, meAiod and article ofmamqfactnre are provided for identifyiBg playback 
devices of a plurality of client q>paratuses wtddi are netwoiked to simultaneously 
playback an event A type of the playback device of each of the cliait ^aratuses is 
first identified. A command associated vdfh the identified type of die playback 
device is then looked 19 in a table. Thereafter, the command is sent to the 
coxtesposdtng cUent ^aratns for beguming the playback of the evmt 
simultaneously with the playback of the evmt on each of the remaining cUent 
apparatuses. 



PROVIDING M EVEOT STORED IN MEMORY ON A PLUR AUTY OF CUE NT AP PARATUSES, 
VVHEREIN T>ffi CUENT APPARATUSES ARE ADAPHTED TO BE CONNECreD TO A HOST 
COMPUTH* VIA A NETWORK 



TRANSMirnWS INFORMATKW FROM THE HOST COMP^ 
APPARATUSES UTIUZING THE r^TWORK FOR AL101MN0 THE SIMULTANEOUS PIAYBACK 
OF THE EVEIfT ON EACH OFTHE CUENT APPARATUSES 



Figure 2 



PROW DING AN EVEOT Sra? ED IN MaUlO RV ON A PUJRALirf OF CUB^ 
WHERBN THE CLOn* APPARATUSES ARE AQAFTED TO BE CONNBnH) TO 
COmVTER A NETVtfORK 
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STCX^IM3 INFORMATION QNTHEKOSTCOmJTERFORALLjO^ 

PLAYBACK OF THE EVENT ON EACH OF THE CUENT APPARATUSES 
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AUOWIN67HE tNFORMAT]C»ITO BE D0WNL0AD53 UTILIZING THE NETWOFUC FOR 
PLAYBACKAFIER THE SWUtTANEOUS PLAYBACK 
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Figure 3 
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SniUlTANEOUSLYPUYINQ BACK AN EVENT ON IHECUENT APPARATUSES UTIUZINQ 

THE NETWORK 
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Figure 4 



CONNECTJNO A PLURMJTY OF CUENT APPARATUSES WV A NETWORK, WHEREIN AN 
EVENT IS STORBD IN MEMORY ON im CUENT APPARATUSES 
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SIMULTANEOUa.Y PUYINQ BACK THE EVENT ON THE CUENT APPARATUSES UTIUZING 

THE NETWORK 
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RECEMNQ A REQUEST FROM ONE OF THE CUENT APPARATUSES DURING THE 
SIMULTANEOUS PLAYBACKTO BE INCUIDED IN THE SYNCHRONIZB) EVENT 
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TRANSMTTING INFORMATTON TO THE REQUESTINQ CUENT APPARATUS UTIUZING THE 

NETWORK FOR IDEKnFYWG A LOCATK>N IN THE RffiMORY WHERE THE EVEOT 
CURRENaV BEING PIAYED BACK SO AS TO AU-OWTHE SIMULTANEOUS PLAYBACK OF 
THE EVENT ON THE REQUESTING CUENT APPARATUS 
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Figure 5 



CONlCanNQ A PLURAUTf OF CUENT APPARATUSES VtA A NETVtfORK 
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EMBEDDING AN APPUCAT30N PROGRAM ON A SfTE ON THE r^TWORK 
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